Jeg er ikke sikker på, hvordan jeg virkelig sætter ord på mit spørgsmål, så lad mig prøve at forklare det med et eksempel: Lad os sige, at mit program løber ind i en underlig opførsel ved en bestemt handling. Jeg finder allerede noget kode, der er årsagen til denne underlige opførsel. Når jeg deaktiverer denne sekvens, løber jeg ikke ind i denne adfærd. Desværre har jeg brug for denne kode, fordi noget andet ikke fungerer dengang. Så hvad jeg skal gøre næste er at finde ud af, hvorfor noget går anderledes, når dette kodeuddrag er aktivt. For bedre at forstå, hvad der foregår, vil jeg nogle gange køre hele handlingen inklusive den 'dårlige kode' og nogle gange uden. Så kan jeg sammenligne resultatet, for eksempel hvad der sker i brugergrænsefladen, eller hvad min funktion returnerer. Den første tilgang, der kommer til mig, er at køre mit program med koden aktiveret, gøre hvad jeg vil, derefter stoppe mit program, kommentere koden, kompilere igen og køre igen. Um ... det lyder dumt. Især hvis jeg igen har brug for at tænde den kode for at se en anden gang den anden adfærd, og derefter igen slukke, tænde og slukke og så videre. Det er ikke en mulighed for mig at bruge breakpoints og påvirke udsagnets rækkefølge eller at ændre værdier, så jeg løber eller ikke løber ind i if-udsagn, for-sløjfer osv. To eksempler: Jeg debugger en kritisk timing for timing, og når jeg stopper programmet, ændres timing betydeligt. Således skal det første breakpoint, jeg kan indstille, være i slutningen af handlingen. 1 Jeg forventer, at der vises et værktøjstip eller et andet vindue, der er 'undertrykt', når VS gives fokus. Således kan jeg slet ikke bruge nogen brudpunkter. Hverken i starten eller slutningen af handlingen.1 Er der nogen teknik i Visual Studio 2012, der giver mig mulighed for at markere denne kode for at være valgfri, og jeg kan beslutte, om jeg vil køre denne kodesekvens eller ej, før jeg udfører handlingen? Jeg tænker på noget som hvis (sandt | falsk) på et højere niveau. Jeg leder ikke efter en løsning, hvor jeg har brug for at køre mit program igen flere gange. I så fald kunne jeg stadig gøre den enkle tilgang ved blot at kommentere koden med #if false. 1 Bemærk, at jeg selvfølgelig kan indstille et breakpoint, når jeg skal se på en bestemt variabel på en bestemt position (hvis jeg ikke har skrevet værdien til output), men vil slå breakpoints fra igen for at køre hele handlingen i en gå.
2020-12-07 23:08:47
I Visual Studio-fejlfindingsprogrammet kan du indstille et brudpunkt lige foran din "aktuelle kode". Når koden stopper på det tidspunkt, kan du vælge at lade den fortsætte, eller du kan højreklikke på en hvilken som helst anden linje og vælge Set Next Statement.
Det er lidt af en underlig mulighed, men jeg er kommet til at sætte pris på det.
|
Den eneste mulighed, jeg kan tænke på, er at tilføje noget til din brugergrænseflade, der kun vises ved fejlretning, hvilket giver dig mulighed for at inkludere / ekskludere de pågældende operationer.
Mens du er ved det, vil du muligvis også aktivere nulstilling af applikationen til en "kendt tilstand" fra brugergrænsefladen.
|
Jeg tænker på noget som hvis (sandt | falsk) på et højere niveau.
Hvorfor "på et højere niveau"? Hvorfor ikke bruge netop dette?
Du vil have et stykke kode, der nogle gange udføres, nogle gange ikke, og kontakten skal ændres ved kørselstid, ikke på kompileringstidspunkt - dette fører naturligvis til
hvis (betingelse)
{
// kode i indsats
}
Fangsten her er, hvilken form for tilstand du vil bruge - måske en variabel, du indstiller til sand i frigivelsesversionen af din kode, og til undertiden falsk i din fejlretningsversion. Måske hentes værdien fra en konfigurationsfil, måske fra en miljøvariabel, måske beregnet af en eller anden form for logik i dit program, uanset og når du vil.
REDIGER: du kan også introducere en boolesk variabel i din kode til tilstand, initialisere den til sand som standard og ændre dens værdi ved hjælp af fejlfindingsprogrammet, når du vil.
|
Forprocessordirektiver er måske det, du leder efter. De er stykker kode, som kompilatoren kan udføre, identificerbare ved at starte med et # tegn (og stilistisk følger de som standard ikke din kodes indrykningsmønster, i stedet for altid at være fast ved den venstre kant af editoren ):
#definer INCLUDE_DODGY_CODE
offentlig ugyldighed MyMethodWithDodgyBits () {
# hvis INCLUDE_DODGY_CODE
myDodgyMethod ();
#Afslut Hvis
myOkMethod ();
}
I dette tilfælde, hvis #define INCLUDE_DODGY_CODE var inkluderet, bliver myDodgyMethod () -kaldet samlet i dit program. Ellers springes opkaldet over af kompilatoren og eksisterer simpelthen ikke i din binære.
|
Der er et par muligheder for fejlfinding, som du beder om.
Visual Studio har en række muligheder for direkte at navigere gennem kode. Du kan bruge funktionen Set Next Statement til at flytte direkte til en bestemt sætning. Du kan også redigere værdier direkte gennem det øjeblikkelige vindue QuickWatch og værktøjstip, der svæver over variabler under fejlretning.
Visual Studio har også evnen til at afspille udførelseshistorikken. Se på IntelliTrace for at komme i gang. Det kan være nyttigt, når du har flere bekymringsområder, der interagerer og genererer fejltilstanden.
Du kan også pakke dine sektioner med kode ind i betingede blokke og indstille de betingede variabler efter behov. Det kan være, mens du debugger, eller du kan videregive parametre gennem en konfigurationsfil. Brug af betingede kontroller kan være lettere end manuelt at gå igennem koden, hvis der er et antal udsagn, du ønsker at ekskludere.
|
Det afhænger undertiden af versionen af VS og sproget, men du kan med glæde redigere koden (for at kommentere den eller indpakke den i et stort #ifdef 0), så tryk på alt + F10, så kompilerer kompileren, lænker igen og fortsætter udførelsen som om du aldrig har fiket med det.
Men mens det fungerer smukt i VC ++ (siden VS v6 IIRC), kan C # have problemer - jeg finder (med VS2010), at jeg ikke kan redigere og fortsætte på denne måde med funktioner, der indeholder eventuelle lambda (hovedsagelig linq) udsagn og 64-bit kode aldrig brugt til at gøre dette også. Det er stadig værd at eksperimentere med, da det nogle gange er virkelig nyttigt.
|
Jeg har arbejdet med applikationer, der har valgfri kode, der bruges til fejlretning alene, der ikke skal vises i produktionsmiljøet. Dette segment af valgfri kode var nemmest for os at kontrollere ved hjælp af en konfigurationsfil, da det ikke krævede en genkompilering for at ændre.
En sådan løsning er muligvis ikke slutningen, alt sammen for dit slutresultat, men det kan hjælpe med at komme igennem det, indtil en løsning er fundet. Hvis du har flere valgfri sektioner, der skal testes i kombination, kan denne rettelsesstil kræve flere nøgler i konfigurationsfilen, hvilket kan være en ulempe og en smerte at holde styr på.
|
Dit spørgsmål er ikke helt klart, hvilket muligvis er grunden til, at der er så mange svar, som du synes er ugyldige. Du kan overveje at omformulere det, hvis ingen ser ud til at kunne besvare spørgsmålet.
Med risikoen for at give et andet ikke-gyldigt svar vil jeg tilføje nogle input til, hvordan jeg har håndteret problemet tidligere.
Den nemmeste måde er at placere en valgfri kode indeni
# hvis DEBUG
// Valgfri kode her
#Afslut Hvis
På den måde, når du kører i fejlretningstilstand, implementeres koden, og når du kører i frigivelsestilstand, er den ikke. Skift mellem de to kræver, at du klikker på en knap.
Jeg har også løst det samme problem på en lignende måde med et simpelt flag:
bool runOptionalCode = false;
derefter
hvis (runOptionalCode)
{
// Placer valgfri kode her
}
Igen,skift mellem tilstande kræver ændring af et ord, så det er en simpel opgave. Du nævner dette i dit spørgsmål, men diskonter det af årsager, der er uklare. Som sagt kræver det meget lidt indsats at skifte mellem de to.
Hvis du har brug for at foretage ændringer mellem koden, mens den kører, er den bedste måde at bruge et UI-element eller et tastetryk, der ændrer det flag, der er nævnt i eksemplet ovenfor. Afhængigt af din ansøgning kan dette dog være mere, end det er værd. Tidligere har jeg fundet ud af, at når jeg har en nøglelytter, der allerede er implementeret som en del af projektet, har et par nøgleslag, der beslutter, om jeg skal køre min debug-kode (valgfri) fungerer bedst. I en applikation uden nøglelyttere vil jeg hellere holde mig til en af de tidligere metoder.
|
Dit svar
StackExchange.ifUsing ("editor", funktion () {
StackExchange.using ("externalEditor", funktion () {
StackExchange.using ("uddrag", funktion () {
StackExchange.snippets.init ();
});
});
}, "kodeuddrag");
StackExchange.ready (funktion () {
var channelOptions = {
tags: "" .split (""),
id: "1"
};
initTagRenderer ("". split (""), "" .split (""), channelOptions);
StackExchange.using ("externalEditor", funktion () {
// Skal redigere editoren efter uddrag, hvis uddrag er aktiveret
hvis (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using ("uddrag", funktion () {
createEditor ();
});
}
andet {
createEditor ();
}
});
funktion createEditor () {
StackExchange.prepareEditor ({
useStacksEditor: falsk,
heartbeatType: 'svar',
autoActivateHeartbeat: false,
convertImagesToLinks: sand,
noModals: sandt,
showLowRepImageUploadWarning: true,
reputToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Drevet af \ u003ca href = \" https: //imgur.com/ \ "\ u003e \ u003csvg class = \" svg-icon \ "width = \" 50 \ "height = \" 18 \ "viewBox = \ "0 0 50 18 \" fill = \ "none \" xmlns = \ "http: //www.w3.org/2000/svg \" \ u003e \ u003cpath d = \ "M46.1709 9.17788C46.1709 8.26454 46.2665 7.94324 47.1084 7.58816C47.4091 7.46349 47.7169 7.36433 48.0099 7.26993C48.9099 6.97997 49.672 6.73443 49.672 5.93063C49.672 5.22043 48.9832 4.61182 48.1414 4.61182C47.4335 4.61182 46.72543 4.916.56 43.1481 6.59048V11.9512C43.1481 13.2535 43.6264 13.8962 44.6595 13.8962C45.6924 13.8962 46.1709 13.2535 46.1709 11.9512V9.17788Z \ "/ \ u003e \ u003cpath d = \" M32.492 10.1419C32.44.064.014.614 12.6 12.4 41.5985 12.6954 41.5985 10.1419V6.59049C41.5985 5.28821 41.1394 4.66232 40.1061 4.66232C39.0732 4.66232 38.5948 5.28821 38.5948 6.59049V9.60062C38.5948 10.8521 38.2696 11.5455 37.0451 11.545.5 521 35.4954 9.60062V6.59049C35.4954 5.28821 35.0173 4.66232 34.0034 4.66232C32.9703 4.66232 32.492 5.28821 32.492 6.59049V10.1419Z \ "/ \ u003e \ u003cpath fill-rule = \" evenodd \ "clip-rule = \" evend = \ "M25.6622 17.6335C27.8049 17.6335 29.3739 16.9402 30.2537 15.6379C30.8468 14.7755 30.9615 13.5579 30.9615 11.9512V6.59049C30.9615 5.28821 30.4833 4.66231 29.4502 4.66231C28.9913.461.46 .1369 4.56087 21.0134 6.57349 21.0134 9.27932C21.0134 11.9852 23.003 13.913 25.3754 13.913C26.5612 13.913 27.4607 13.4902 28.1109 12.6616C28.1109 12.7229 28.1161 12.7799 28.121 12.8346C28.125 12.222.230 15.2321 24.1352 14.9821 23.5661 14.7787C23.176 14.6393 22.8472 14.5218 22.5437 14.5218C21.7977 14.5218 21.2429 15.0123 21.2429 15.6887C21.2429 16.7375 22.9072 17.6335 25.6622 17.6335Z2424.266 27.2119 7.09766 28.0918 7.94324 28.0918 9.27932C28.0918 10.6321 27.2311 11.5116 26.1024 11.5116C24.9737 11.5116 24.1317 10.6491 24.1317 9.27932Z \ "/ \ u003e \ u003cpath d = \" M16.8045 11.9512C16.280.26 19.8079 13.2535 19.8079 11.9512V8.12928C19.8079 5.82936 18.4879 4.62866 16.4027 4.62866C15.1594 4.62866 14.279 4.98375 13.3609 5.88013C12.653 5.05154 11.6581 4.62866 10.3573 4.62866C9.34336 4.62866 8.59806 4.899 5.00066 5.28821 5.00066 6.59049V11.9512C5.00066 13.2535 5.47873 13.8962 6.51203 13.8962C7.54479 13.8962 8.0232 13.2535 8.0232 11.9512V8.90741C8.0232 7.58817 8.44431 6.91179 9.53458 6.91179C10.510 6.8 C13.4375 13.8962 13.9157 13.2535 13.9157 11.9512V8.90741C13.9157 7.58817 14.3365 6.91179 15.4269 6.91179C16.4027 6.91179 16.8045 7.58817 16.8045 8.94108V11.9512Z \ "/ \ u003e \ u003cpath d = \ "M3.31675 6.59049C3.31675 5.28821 2.83866 4.66232 1.82471 4.66232C0.791758 4.66232 0.313354 5.28821 0.313354 6.59049V11.9512C0.313354 13.2535 0.791758 13.8962 1.82471 13.89622.813.2535 3.31675 11.9512V6.59049Z \ "/ \ u003e \ u003cpath d = \" M1.87209 0.400291C0.843612 0.400291 0 1.1159 0 1.98861C0 2.87869 0.822846 3.57676 1.87209 3.57676C2.90056 3.57676 3.7234 1.9266 0.400291Z \ "fill = \" # 1BB76E \ "/ \ u003e \ u003c / svg \ u003e \ u003c / a \ u003e",
contentPolicyHtml: "Brugerbidrag licenseret under \ u003ca href = \" https: //stackoverflow.com/help/licensing \ "\ u003ecc by-sa \ u003c / a \ u003e \ u003ca href = \" https://stackoverflow.com / legal / content-policy \ "\ u003e (content policy) \ u003c / a \ u003e",
allowUrls: sandt
},
onDemand: sandt,
discardSelector: ".discard-answer"
, straksShowMarkdownHelp: true, enableSnippets: true
});
}
});
Tak for dit bidrag til Stack Overflow!
Sørg for at besvare spørgsmålet. Giv detaljer og del din forskning!
Men undgå ...
At bede om hjælp, afklaring eller svar på andre svar.
At afgive udsagn baseret på mening; sikkerhedskopier dem med referencer eller personlig erfaring.
For at lære mere, se vores tip til at skrive gode svar.
Kladde gemt
Udkast kasseret
Tilmeld dig eller log ind
StackExchange.ready (funktion () {
StackExchange.helpers.onClickDraftSave ('# login-link');
});
Tilmeld dig ved hjælp af Google
Tilmeld dig ved hjælp af Facebook
Tilmeld dig ved hjælp af e-mail og adgangskode
Indsend
Send som gæst
Navn
E-mail
Påkrævet, men aldrig vist
StackExchange.ready (
funktion () {
StackExchange.openid.initPostLogin ('. New-post-login', 'https% 3a% 2f% 2fstackoverflow.com% 2fquestions% 2f19425104% 2fcan-i-mark-some-code-as-optional-while-debugging-in- visual-studio-2012% 23new-answer ',' question_page ');
}
);
Send som gæst
Navn
E-mail
Påkrævet, men aldrig vist
Send dit svar
Kassér
Ved at klikke på “Send dit svar” accepterer du vores servicevilkår, fortrolighedspolitik og cookiepolitik
Er det ikke det svar, du leder efter? Gennemse andre spørgsmål tagged debugging visual-studio eller stil dit eget spørgsmål.